home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950726-19950929 / 000292_news@columbia.edu_Mon Sep 4 11:00:19 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA29413
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 4 Sep 1995 19:15:59 -0400
  3. Received: by apakabar.cc.columbia.edu id AA26350
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 4 Sep 1995 19:15:57 -0400
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
  9. Message-Id: <1995Sep4.170019.60531@cc.usu.edu>
  10. Date: 4 Sep 95 17:00:19 MDT
  11. References: <42d2u9$edt@apakabar.cc.columbia.edu> <2979@sun3.IPSWITCH.COM>
  12. Organization: Utah State University
  13. Lines: 97
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16.     Supplementing Dan's decent advice...
  17.  
  18. In article <2979@sun3.IPSWITCH.COM>, ddl@harvard.edu (Dan Lanciani) writes:
  19. > In article <42dodl$go@apakabar.cc.columbia.edu>, chaiklin@konichiwa.cc.columbia.edu (Seth Chaiklin) writes:
  20. > | 
  21. > | Joe Doupnik <jrd@cc.usu.edu> wrote:
  22. > | >    Did you have a chance to look at the ARP cache on the Linux machine?
  23. > | >I've heard rumors (I don't use Linux) that it times out and can yield just
  24. > | >the effects noted. You might try pinging MSK from the Linux end as one way
  25. > | >of correcting its ARP cache.
  26. > | 
  27. > | You are definitely on the right track (and thanks for the fast response!).
  28. > | 
  29. > | I tried an experiment.  I let the MSK machine sit idle while
  30. > | connected to the Linux machine, and after 10 minutes (while true;
  31. > | do date; arp -a; sleep 60; done), I discovered that the Linux arp
  32. > | cache loses the HW address of the ethernet card, at which point,
  33. > | of course, the MSK machine appears to be frozen.
  34. > 
  35. > Note that most implementations intentionally time out ARP entries; this
  36. > is a feature.  I doubt that the entry is lost as such, though timeouts
  37. > are usually a bit longer.  You may be looking at an ARP bug in Linux
  38. > or kermit involving bad behavior when one side already knows the address.
  39. > These kinds of bugs come up more often than you might imagine since
  40. > the ARP process for mainly-client programs is usually one way and the
  41. > reverse process may be only lightly tested.  Keep in mind that the answerer
  42. > of an ARP request also retains the address of the caller to avoid sending
  43. > an ARP itself.  Starting with both machines ignorant of the hardware
  44. > addresses, the process might go like this:
  45. > 
  46. > kermit -> ARP-REQUEST -> Linux (saves kermit's hardware address)
  47. > Linux -> ARP-RESPONSE -> kermit
  48. > 
  49. > Since this is the most common sequence, kermit probably doesn't have to
  50. > answer ARP requests at all most of the time.
  51.  
  52.     True, but MSK does answer ARPs all the time the TCP stack is
  53. active (while there is a session going). MSK does regular ARP caching
  54. too, but it does not timeout the entries for the currently used remote
  55. hosts. The bug seems to be in Linux.
  56.  
  57. > | I tried pinging the MSK machine from the Linux machine, but it
  58. > | does not respond.  However, if I hand-entered the HW address for
  59. > | the MSK machine, then deleted this entry from the arp cache, and
  60. > | then added it again, I could reestablish input/output being shown
  61. > | on the MSK machine, and everything seems to work as it should.
  62. > 
  63. > You'd need a network trace to be sure, but this suggests that kermit
  64. > isn't responding to ARPs in its current state.  (It could also be that
  65. > Linux isn't sending them at all, but that would be such a devastating
  66. > error that it would have been noticed long ago.  I hope.)  I think there
  67. > are at least two additional experiments that might shed light on the situation.
  68. > First, while in the bad state, try to ping it from another machine that
  69. > has never been involved with the connection at all.  This should tell
  70. > you whether kermit is willing to respond to anybody's ARP at this point.
  71. > If it doesn't respond then it has somehow been corrupted (or doesn't
  72. > respond to ARPs in general).  If it does respond then it may be that kermit
  73. > has a problem answering ARPs when it already knows the peer's hardware
  74. > address.  If it does not respond, move on to the next test:
  75. > 
  76. > Start kermit fresh and don't connect to anything (I assume you can do this
  77. > and still have the tcp running?).  Now try to ping kermit from a machine
  78. > which has no ARP entry for kermit.  If this works and the first test failed
  79.  
  80.     This won't work as intended because MSK does not run its TCP/IP stack
  81. until a session has started (or is starting). After all, why run a TCP/IP 
  82. stack if it's not being used?
  83.     Probing MSK and the Linux box from a third uninvolved machine is
  84. a good thing to do, however. Ping and traceroute both work with MSK.
  85.     Something else to keep in mind is another station coming on the
  86. air with MSK's IP number. That clobbers ARP caches. MSK 3.14 checks for
  87. another station using it's IP address when the TCP/IP stack is started.
  88. (It ARPs for its own IP number and declares any response an imposter. I
  89. had to insert an special case to work around echoing by NDIS drivers.)
  90.  
  91. > then it is likely the program is becoming corrupted somehow.  If the second
  92. > test fails then kermit doesn't respond to ARPs at all (seems unlikely) or
  93. > you have some obscure problem with broadcasts and/or frame types that is
  94. > blocking ARPs in one direction.  (Don't laugh; I've seen it.)
  95.  
  96.     I'm not laughing either. I've encountered worse.
  97.  
  98. > The general idea is that things can work remarkably well with ARPs functioning
  99. > in only one direction and it takes something like a short cache timeout to
  100. > bring the problem to light.  Consider that one end could be totally incapable
  101. > of receiving broadcasts (bad NIC, bad driver, etc.) and it would still appear
  102. > to function normally as long as it always ARP'ed first and the peer had a long
  103. > timeout.
  104.  
  105.     There are still some rather unusual (eg, wierd) situations where ARP
  106. responses simply don't get through. I don't know why, but they don't. One
  107. always suspects one piece of code or another and probably one does have a
  108. problem, but the saying "it does not happen here" applies to make diagnosis
  109. difficult.
  110.     Joe D. 
  111. >                 Dan Lanciani
  112. >                 ddl@harvard.*